The CCM (CORBA Component Model) standard, maintained by the OMG (Object Management Group), is a software development approach by assembling elementary entities. This standard thus groups together the notion of software components and that of communication using the CORBA standard between two such components.
A component is a design, implementation, deployment and execution entity, including a wrapper part, making it possible to interface that entity with other entities within the application according to predefined interaction modes, and a business logic code part, encapsulated in the wrapper and making it possible to specify the particular processing performed by that software entity.
CORBA (Common Object Request Broker Architecture) is a communication middleware between components, which allows transparent management of the communication between two components of the application, irrespective of the deployment plan of the application, i.e., how the various entities making up the application are installed on several platforms connected to each other by a network so as to form a computer installation. Thus, when the deployment plan leads to two components needing to exchange data being executed on two different platforms, the CORBA middleware manages all of the aspects of the communication on the network connecting those platforms.
In the case of asynchronous interactions (“events”), this management is done by calling on the CORBA CosNotification notification service. This requires implementing the GIOP protocol (General Inter-ORB Protocol). An ORB (Object Request Broker) is a software entity of the CORBA middleware capable of converting (“serializing”) the structure of a datum during processing on the first platform, and a sequence of bytes that can be transmitted over the network to a second platform, on which the datum, after having undergone the inverse conversion by another ORP, will finished being processed.
The CCM standard defines synchronous and asynchronous communication modes between two components.
In the synchronous mode, a first component transmitting an initial datum to a second receiver component suspends the execution of its business logic code as long as the second component has not returned a suitable response message to it. This response message may for example include an acknowledgment datum acknowledging receipt of the initial datum or a datum resulting from processing of the initial datum done by the second component.
In asynchronous mode, a first component transmitting an initial datum to a second receiver component resumes the execution of its business logic code upon transmission of the initial datum, without waiting for a response message from the second receiving code.
The LwCCM (Light weight CORBA Component Model) standard is a subset of the CCM standard that was defined to meet the particular needs of software applications designed to be executed on onboard systems. Such a software application must comply with the major stresses that exist in terms of size in the memory space and consumption of the computation capacities (CPU) of the onboard system.
It must also lead to a low energy consumption.
Furthermore, the software applications intended for onboard systems often serve to perform preprocessing on the acquired data, that preprocessing having to be done in real-time.
Hereafter, “real-time” refers to operation of the application in a characteristic time shorter than a specific time of the system. For example, in the case of the preprocessing of a high-definition video image obtained as output from a camera operating at 24 frames per second, the preprocessing done on each image by the software application must be done in less than 20 ms. Consequently, within the software application, each processing operation done by a component of the application, as well as the communication between two components of that application, must also be done in less than 20 ms.
However, it has been observed that the CORBA Middleware does not make it possible to produce applications operating in real-time, since the exchange of data between two components, based on the CORBA notification service, is relatively low performing and consumes a relatively significant portion of the CPU. As a result, the time necessary to exchange data between components is non-negligible relative to a specific time of the system.
This relative slowness of the communications between two components is accentuated when the quantity or nature of the data to be exchanged between components generates a significant flow. For example, for the preprocessing of a high-definition video image, a data flow of approximately 50 MB must be able to be exchanged between two components.
Thus, while real-time onboard applications need high-speed asynchronous communications, the LwCCM standard does not provide the necessary communication means. Furthermore, it does not make it possible to exchange data of various natures: audio flow, video flow, radio flow, etc.